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1 ) 


WHY IS OBJECT-ORIENTED DEVELOPMENT <00D> IMPORTANT? 


00D is one of the extremely feu software development methods 
actually designed for modern Ada <*) language* real-time* 
embedded appl ications. 


00D is a significant improvement over more 
decomposition and modeling methods in that 


traditional 

00D: 
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a) Better manages the size* complexity* and concurrancy 
of today’ s systems. 

b) Better addresses important softuare engineering 
principles such as abstract data types* levels of 
abstraction* and information hiding. 

c) Produces a better design that more closely matches 
rea 1 i ty . 

d) Produces more maintainable softuare by better localizing 
data and thus limiting the impact of requirements changes. 

e) Specifically exploits the power of Ada. 


2) WHAT IS 00D? 


00D is a systematic, step-by-step software development method that: 


a) Has an optimal domain of application — the development of 
modern Ada applications (e.g.* real-time* embedded software). 

b) Covers all* or a major portion, of the softuare life-cycle. 

c) Supports extensive parallel development. 

d) Manages the complexity of large development efforts. 

e) Is supported by detailed standards and procedures. 

f) Requires training and Bupport to be effective. 


00D is: 


a) Object-oriented. 

b) Ada-oriented. 


( # ) 


Ada iB a registered trademark of the U.S. Government (AJPO). 
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c) Based upon modern software engineering. ^ 

d) Recursive, globally top-down, hierarchical COHPOSITION 
method. 

e) Revolutionary in approach. 

f) A "grab and go" method. 

g) Relatively easy to learn. 

h) Being successfully used by several companies. 

1) Still evolving (see Figure 1). 



Figure 1! The evolution of 00D 
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OOD is NOT* 


a) A functional, hierarchical DECOMPOSITION method. 

b) A modeling method. 

c) Easily mated uith such methods. 

d) Effective without adequate training. 

e) Constrained to the claeeical "waterfall" lifecycle. 

f) Consistent with DOD-STD-2167 and related pre-Ada standards. 

g) Standardized across the industry. 

h) Yet adequately supported by commercially available software 
tools. 


3) 


OOD IS OBJECT-ORIENTED. 


An OBJECT is an entity that: 

a) Has a value <e.g.» data) or state (e.g.» Ada task). 

b) Suffers and/or causes operations. 

OOD produces: 

a) Ada objects that correspond to objectB in the real world. 

b) Ada types (i.e.* object templates). 

c) Operations that operate on these objects. 

OOD emphasizes the implementation of objects in terms of 
ABSTRACT DATA TYPES. OOD groups, in the same Ada package: 


a) A single type and 

b) All operations that operate upon such objects. 

OOD produces a substantially different software architecture 
than traditional functional decomposition methods such as 
Structured Design which generate units* each of which implements 
some FUNCTION of the requirements specification. 


4) OOD IS ADA-ORIENTED. 

Ada is an object-oriented high-level language. 

Packages* which are the main building blocks of properly designed 
Ada software* are also the main building blocks produced by OOD. 

The physical design produced by OOD is top-down in terras of Ada: 


a) Nesting and 

b) Context (i.e.* the Ada H w 


OOD separately develops Ada spec 

OOD’s low-level testing natural 1 
order constraints. 


ith M statement 
i f icationB and 
y accounts for 


bod i es. 

Ada compilation 
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OOD Diagrams claarly identify the various Ada programming units. 

Ada PDL is an integral part of OOD 9 s design and coding straps. 

The objects produced by OOD are implemented in Ada as: 

a) Constants and variables 

b) Abstract data types 

c ) Tasks 

The operations produced by OOD aro implemented in Ada primarily ae* 

a) Subprograms 

b) Task entries 


5) OOD IS BASED UPON MODERN SOFTWARE ENGINEERING. 

OOD specifically addresses each of the following software 
engineering principles or concepts: 


a) ABSTRACT DATA TYPES. i> 

b) ABSTRACTION LEVELS. j) 

c) Cohesion. k) 

d) Concurrency. 1) 

e) Coupling. a) 

f) INFORMATION HIDING. n) 

g) Localization. o) 

h) MAINTAINABILITY. 


MODULARITY. 
Organizational 
Readabl 1 i ty. 
Reusabi 1 i ty . 
Structure. 
Testabi 1 1 ty 
Veri f iabi 1 1 ty. 


I ndependence. 


6) OOD IS RECURSIVE* GLOBALLY TOP-DOWN* HIERARCHI AL COMPOSITION METHOD. 

Traditional software development methods are restricted to the 
classic W waterfair life-cycle (see Figure 2) in which: 


a) The software requirements are analyzed first. 

b) The preliminary design is developed second. 
The detailed design follows. 


c ) 
d) 


And so on. 


< 3 * < 3 > <3 (3 


SYSTEN/SOF TWAftE 
REQUIREMENTS 
ANALYSIS 


SOT T*ARE 
REQUIRE* NTS 
ANALYSIS 


PRCL IMJNARY 
DESIGN 


Of TAILED 
DESIGN 


C DOING UNIT 
TESTING ANO CSC 
INTEGRATION 
TESTING 


CSC I 
TESTING 


Figure 2: The classic "water f al 1 " life-cycle 
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Because the software im developed in a top-down manner only within 
the boundriem o 1 each life-cycle phase* these methods are at beet 
only locally top-down. 

ODD is a recursive* globally top-down* hierarchial composition 
method. Its software life-cycle (see Figure 3) differs significantly 
from the classic "water f al 1 " life-cycle because it is based upon 
recursion and two concepts unique to OOD* the Booch and Subbooch. 

A BOOCH is the collection of all software resulting from the 
recursive application of 00D to c specific set of coherent 
software requirements — requirements that specify a single 
uel 1 -defined problem. 

A SUBBOOCH is a small* managable subset of a booch that is 
Identified and developed during a single recursion of OOD. 

See Figure 4. 

Note that these two concepts have no obvious natural relationship to 
the OoD hierarchical decomposition entitles C5CI* TLC5C. and LLCSC. 

Beginning with the highest abstraction level and progressing 
steadily downwards in terms of nesting and "withing". the booch 
is designed* coded* and tested in Increments of a subbooch. Thus* 
the software grows top-down* subbooch by eubbooch* via the 
recursive application of OOD until the entire software tree 
is completed. 

Locally* however* OOD employe the appropriate technique 
(top-down or bottom-up) depending upon the specific requirements 
of each individual development activity. 

This allows very significant parallel development baaed upon the 
"Design a little, code a little* test a little" concept. 


7) RESPONSIBILITIES. 

The foliouing personnel have OOD reaponsibl i ties (see Figure 5): 

a) Management 

b) Software Development Teams, each consisting of a: 

- Designer 

- Programmer 

- Tester 

c) Metrics Collectors 

d) Software Quality Evaluation 

e) Software System Engineering 


8) SUBBOOCH DEVELOPMENT 

The subbooche that comprise each booch are recursively developed 
in a globally top-down fashion. The development of each subbooch 
consists of the foliouing three subphaeess 
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B0QCh BOOCH DELIVERABLE on nrw 

integration f » j c t IOnal DOCUMENT 
iNit&RATicw T£ST PRODUCTION ^VIEW 


Figure 3: The 00D software life-cycle 
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a) Subbooch Requirements. 

b) Subbooch Demign. 

o) Subbooch Coda and Taat. 

Tha SUBBOOCH REQUIREMENTS SUBPHASE haa tha following atapai 

INITIATION OF SUBBOOCH DEVELOPMENT - Tha Hanagar initiates 
aubboooh davalopaant by ldantl tying tha membara of the 
associated Software Davalopaant Teas and tasking them to 
meat an assigned aohadula of subbooch milestones. 

INITIATION OF SOFTWARE DEVELOPMENT FILE (SDF) - The Designer 
Initiates tha associated SDF by obtaining an empty SDF 
binder and inserting tha initial Software Engineering Forme 
(SEFS) that make up tha covarpages. 

PROBLEM STATEMENT - Tha Software Development Team jointly 
state in a single sentence the problem to be solved during 
the currant recursion. 

REQUIREMENTS ANALYSIS - The Software Development Team jointly 
collect, analyze, clarify, organize, and identify the subbooch 
requirements. 

SUBBOOCH REQUIREMENTS INSPECTION - The Designer prepares the 
SDF for inspection. The Manager schedules the associated 
meeting. The Manager, the Programmer, and the Teeter perform 
the inspection. The Software Development Team takes any 
appropriate corrective action. 

The SUBBOOCH DESIGN SUBPHASE has the following steps: 

LOGICAL DESIGN - The Software Development Team (under the 

leadership of the Designer) develops in a single paragraph 
a logical design that properly solves the problem of the 
current recursion and identifies the relevant objects and 
operat i one. 

OBJECT ANALYSIS - The Software Development Team (under the 
leadership of the Designer) analyzes all relevant objects 
in the logical design paragraph, determines and documents 
their relevancy, and provides the relevant objects with 
valid Ada Identifiers, brief descriptions, and a list of 
associated attributes. 

OPERATION ANALYSIS - The Software Development Team (under the 
leadership of the Designer) analyzes all relsvant operations 
in the logical design paragraph, determines and documents 
their relevancy, and provides the relevant operations ulth 
valid Ada identifiers, brief descriptions, and a list of 
associated attributes. 

MODULE IDENTIFICATION. ORGANIZATION. AND DEPENDENCIES - The 
Software Development Team (under the leadership of the 
Designer) organizes all relevant objects and operations 
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by types* identifies ths non-neeted units for each such 
organization* nssts the organized objects and operations 
within these units* and determines the visible dependencies 
between these units. 

SUBBOOCH PRELIMINARY DESIGN INSPECTION - The Designer prepares 
the SDF for inspection. The Programmer and Tester perform 
the Inspection. The Software Development Team takes any 
appropriate corrective action. 

DESIGN ANALYSIS - The Software Development Team (under the 

leaderehlp of the Designer) analyzes the design* Identifies 
the type of the nested units* common software* and nested 
units requiring recursion* etc. 

CODING OF UNIT SPECIFICATIONS - The Software Development Team 
(under the leadership of the Designer) implements and 
compiles* in a bottom-up manner in terms of unit dependencies* 
the Ada specifications of all units. This includes the 
development of specification headers* PDL* comments* and 
code from skoleton unit specifications. 

SUBBOOCH DETAILED DESIGN INSPECTION - The Designer prepares 
the SDF for inspection. The Motrlcs Collector collects* 
summarizes* and reports the subbooch design metrics. 

The Programmer and Tester perform the Inspection. The 
Softuare Development Team takes any appropriate corrective 
action. 

The SUBBOOCH CODE AND TEST SUBPHASE has the following steps* 

CODING OF UNIT BODIES - The Softuare Development Team (under 
the leadership of the Programmer) Implements and compiles* 
in a top-down manner in terms of unit dependencies* the 
Ada bodies of all unite to be implemented during the current 
build. This includes the development of body headers* PDL* 
comments* and code from ekeleton unit bodies using the 
technique of step-wise refinement. 

SUBBOOCH TEST PLAN - The Softuare Development Team (under 
the leadership of the Teeter) develops the test plan by 
determining* creating files of. and documenting the teet 
input and expected teet output data required for all 
subbooch testing and documenting the allocation of these 
test cases to specific subbooch tests. 

SUBBOOCH TEST SOFTUARE - The Software Development Team (under 
the leadership of the Tester) designs* implements* and 
compiles all test software programs required for subbooch 
testing scheduled for the current build. 

SUBBOOCH TEST PROCEDURES - The Softuare Development Team (under 
the leadership of the Tester) develops the detailed step-by- 
step procedures for performing all subbooch tests scheduled 
for the current build. 
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SUBBOOCH CODE INSPECTION - Ths Programmer prepares the SDF for 
inspection. The Metrics Collector collects* summarizes* 
and reports the eubboooh code metrics. The Software 
Development Team perform the Inspection. The Softuare 
Development Team takee any appropriate corrective action. 

INITIAL SUBBOOCH TESTING - The Softuare Development Team 

(under the leadership of the Teeter) perform and document 
the reeulte of all initial eubboooh teste. 


9) PRACTICAL EXPERIENCE. 

The use of 00D at flagnavox on the AFATDS Project (over 50K 
lines of Ada code bo far) has resulted in the following lessons 
1 earned * 

a) Avoid overspecifying the requirements with explicit or 
implicit design information of a functional docompoe 1 t i on 
nature. 

b) If a functional decomposition method is used to produce the 
top-level design* it will be incompatible with the design 
produced by ODD at the lower-levels and numerous Interface 
problems will result. 

c) Replacing the previous functional decomposition mindset is 
difficult* primarily among the more experienced designers. 

d) The concept of recursion is fairly difficult to maBter. 

e) 00D training and support in the method needs to continue 
beyond the classroom. 

f) 00D needs to be further refined* primarily in the area of 
object-oriented requi rements analysis. 

g) Ada-oriented test training is as necessary as training 
in Ada-oriented design and programming. 

h) 00D improves designs due to: 

Proper abstraction 1 eve 1 e. 

Proper information hiding. 

High modularity. 

Improved interfaces. 

Good suppo rt for strong typing. 

Good cor respondance to the real world. 

l) 00D improves productivity due to: 

Enhanced parallel development. 

Reuse of code. 

Easy coding from design information. 

Easy modification of design and code. 
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